1. Field of the Invention
The present invention relates to an architecture for an information processing system.
More particularly, it relates to an architecture for large scale systems of the type known as "mainframes".
2. Description of Related Art
Systems of this type, which are very complex, integrate large numbers of subsystems, both hardware and software, which cooperate with one another. It is not unusual for the software products that are components of these systems to comprise hundreds of thousands, if not millions of lines of code.
In this context, one of the most difficult problems to solve is to obtain consistency and compatibility between the various components, particularly when they must be updated (change-overs to more recent versions, addition of modules or functions, etc.).
In addition to the intrinsic complexity noted, it is also necessary to take into account the fact that the various products comprising the system are from different sources, whether internal (even when common development rules are in force) or external (products available on the market).
In the prior art, there are two main types of architectures.
A first architecture belongs to the so-called "proprietary" type. This term designates systems whose architecture is designed by the computer hardware manufacturer.
This architecture is essentially characterized by advanced integration, and exists in the form of a monolithic system. FIG. 1 attached to the present description schematically illustrates an architecture of this type.
The system 1 of FIG. 1 comprises a hardware platform 10 that cooperates with a monolithic set 11 of software systems. These may include an operating system 110, or "OS", a management system 111, which supervises the system functions, and a production system 112. The latter can include, for example, database managers 113, and transaction processors 114. The hardware platform 10 comprises the usual devices of an information processing system: central processing unit, central storage, mass storage, etc., which need not be described in further detail.
In the system of FIG. 1, all the components of the monolithic set 11 are supported during the initial installation and during subsequent updates (changes in the version of the system 1). In this type of environment, the consistency of the system is obtained through the global validation of the interfaces between all the components. For the user, these dispositions guarantee a substantial robustness of the system regardless of its evolution. Moreover, they allow simplified monitoring of the successive versions of the system. Lastly, they ensure maximum availability and high security in operation, since the risks of malfunction are reduced to a minimum.
However, they also entail constraints and serious drawbacks.
These arise from the fact that the systems are monolithic. Regardless of the component to be changed and/or the function to be added, it is necessary to upgrade the entire system. The update can only occur globally.
A practical way to illustrate this drawback is to consider, by way of example, the case of a user who only wants to replace the database management software 113, or to update it with a more recent version. In this hypothesis, the user would be obligated to install a new version of the entire system.
This presupposes, moreover, that this new version comprising the database management software to be replaced or updated is available.
Finally, it results in a substantial amount of unavailability of the information processing system, usually several days for very large scale systems.
It follows that this type of architecture has relatively little flexibility and affords limited possibilities for upgrading.
A second architecture belongs to the so-called "open" type. This term designates open systems whose architecture is not defined by a single manufacturer. These open systems have appeared, in particular, with the emergence of operating systems of the "UNIX" (registered trademark) type or similar systems, for example "AIX" (registered trademark).
It is clear that this type of architecture is very advantageous, since it makes it possible to have software that it heterogeneous, that is, from various sources, coexist in the same machine.
For this type of architecture, the installation and/or updating of software involves only the product itself, and not the system as a whole.
Since basic components can be installed or updated at any time, an "open" architecture offers very high flexibility and substantial ease of upgrading, at least in theory.
In reality, this type of architecture is not exempt from drawbacks, either. In particular, it offers no guarantee of proper operation with the other software components and there are potentially various incompatibility problems.
However, despite its inherent drawbacks, a system with an open architecture remains very advantageous for users.
In effect, it makes it possible to fully or partially meet the needs of information systems users, which currently include, among other things:
autonomy, that is, the ability to upgrade one or more products of the system independently from the rest of the system; PA1 parallelism, that is, the ability to run several versions of the same product simultaneously; PA1 compatibility, that is, being able to rely on a guarantee of forward compatibility of the products and of the interfaces between products; PA1 updating during the normal operation of the system, that is, being able to change versions of a product without stopping operation, or at least with a minimal stop; PA1 back-out capability, that is, the ability to return to an earlier version of a product in case of a problem, without stopping operation; PA1 upgrade control, that is, the capability to remain in control of the upgrade process using automated and simplified procedures; PA1 and fast upgrades and maintenance, that is, being able to count on a minimum delay between a request for an upgrade or a correction and its effective installation on site. PA1 update flexibility: there is never any need to update the entire system, since updates can be performed domain by domain. PA1 reduced unavailability of the machine: the update can be performed in several phases, and those relative to some domains which require a halt in production can take place at selected times. In an advantageous variant of the invention, most of the domains can be updated on a secondary copy during which production continues on a primary copy. Only the final switch-over, for specific domains, may involve a halt in production. PA1 security of version changes: since some domains can run in more than one occurrence, they allow testing and back-out phases in case of a problem. PA1 reduction of update times: since the updates are performed at the domain level, their execution can be studied and planned to best advantage, in accordance with operating constraints. PA1 flexibility in the choice of configurations installed: the user has the ability to install only the domains that are necessary and to completely control the upgrading of the versions of each domain, limited only by the constraints imposed by the possible dependencies and the support and maintenance conditions.